With the increase of multimedia devices in cars, such as CD / DVD players, digital TVs, etc., the intranet connecting these devices includes: Bluetooth, CAN, D2B, FireWire, MOST, Mobile Media Link (MML), LIN and ZigBee Wait, this article introduces an architecture for remote diagnosis interface based on Bluetooth technology, which enables test engineers to monitor and operate the sensors and control unit of the car to complete the test task no matter where it is inside or outside the car. . The future remote diagnostic system will provide an unprecedented access to the car's power controller, whether the car is in a repair shop or on the road. Wireless technologies such as Bluetooth provide the features required for short-range wireless communication between the car technician ’s laptop computer and the in-car network, allowing the technician to monitor and operate the car no matter where it is inside or outside the car Sensor and control unit. From the perspective of automotive technicians, the front end of this network is a telematics control unit (TCU), which connects various networks interconnected with an integrated networked vehicle (INV). At present, there is an obvious trend in the automotive industry, which wants to develop a centralized service gateway model for INV, and Bluetooth technology provides a connection scheme for many links in the network. By providing wireless connection and hoc networking, it complements the existing CAN (Controller Area Network) bus. Other communication media also have their own advantages, such as MOST (Media Oriented System Transmission) and IEEE1394, which provide high-bandwidth audio / video communication for consumer electronics and entertainment systems. This new technology uses the CAN bus to achieve highly reliable communication between systems that have an impact on vehicle performance and safety. The high-speed CAN network is used to connect the engine control unit (ECU), anti-lock braking system (ABS) and other critical systems. Low-speed CAN networks are often used to achieve multi-channel connections. In this network, multi-lamp illuminators, power windows, power seats, etc. are used as nodes on the CAN bus, rather than using large, expensive cable bundles through traditional Connect point-to-point connections. This paper introduces an architecture for remote access diagnostic interface based on Bluetooth technology. In this architecture, Bluetooth networking protocol is used to provide the underlying transmission (physical) medium for an HTTP-CAN gateway. With the help of the embedded HTTP server running on the TCU, service technicians can monitor and control the nodes on the INV from the web browser of the Bluetooth-enabled laptop. This wireless interface provides a convenient way of access, from the bottom of the car, under the hood or inside the passenger compartment. The system described in this article uses the Bluetooth dial-up networking (DUN) feature to emulate an external modem to support a web browser that "dials" to the car's CAN network. By using standard communication protocols such as TCP / IP, and embedding the corresponding software of the car in the HTTP server, the technician's hardware and software are fully scalable relative to the car design, even if the car is maintained by different manufacturers, models and model years It is completely different from the repair process. Diagnostic access to the in-vehicle network Figure 1 shows the network architecture of an intranet that is accessed using a Bluetooth-based diagnostic system. The web browser on the conventional laptop with Bluetooth function is used to access the TCU, which provides a user interface to access the car network. By embedding a diagnostic interface in the car itself, manufacturers can customize the description of the data and the process of submitting it to technicians. Diagnostic procedures can also be provided based on the installation of options in a particular car. In addition to the options selected by consumers such as air conditioners and ABS, there are usually some other component differences that consumers cannot see. For example, 2 to 3 pumps may be used in a model year. After taking all these differences into account, there may be dozens of combinations. Customizing a special diagnostic interface for a specific car reduces the possibility of causing technicians to get lost and use incorrect diagnostic procedures. This interface can be used to access real-time working data while the car is driving and historical data from the controller that records abnormal events (such as engine ignition failure, overtravel sensor data, etc.) logs. The controller can also be used to control automotive sensors for testing, such as verifying that the injection control device can respond properly to the sensor input. The diagnostic system can also recover data for car manufacturers to develop indicator models before failures occur. By uploading the data log in the flash memory and correlating it with the fault report provided by the technician, the learning algorithm can be used to optimize the automatic diagnostic tool. The purpose of the maintenance and repair equipment to provide this information is to assist the diagnosis of the car. When diagnosing a problem in a car, the first step should be to upload flash data, because hiring skilled technicians is relatively expensive, and using the car manufacturer ’s software tools can often diagnose the problem (or provide useful suggestions) ). Internet model Since the system requires networks with different reliability and bandwidth, a variety of network types will be used in the future in-car network. The combination of layered protocol and central gateway processor can realize transparent communication between different networking technologies. With the ongoing revolution in the structure of automotive electronics products, many emerging networks have emerged. Multimedia devices in automobiles, such as CD / DVD players, digital TVs, etc., require a network with a large synchronization bandwidth; while other applications require a wireless network or other configuration. To meet the demand for these extensive and growing automotive network applications, researchers are developing many dedicated network protocols. The future car intranet is likely to include: * Bluetooth piconet (Piconet): a medium-bandwidth wireless network that has become the standard for communication with cellular phones and portable computers. * CAN network: a medium-bandwidth, high-reliability wired network that is already a standard in the automotive industry. * Audio / video network: high-bandwidth wired network for entertainment media. There are currently several competing protocols in this application area, including the internal data bus (D2B), FireWire (FireWire, IEEE 1394), media-oriented system transmission (MOST), and mobile media link (MML). * Low-overhead wired network: UART-based wired network (LIN) and chip-to-chip buses, such as I2C, SPI, and Microwire, support low-cost interfaces to key boards, displays, and sensors. * Low-overhead wireless network: a low-bandwidth wireless network based on ZigBee or a private network, used for radio frequency remote keys for tire pressure sensors, alarms, and door locks, as well as other applications that require wireless interfaces and the lowest cost The future in-car network will usually include multiple CAN networks: low-speed networks are used for door locks, tail lights and other devices, which can reduce wiring; high-speed networks are used for key high-performance functions such as power control. In the 7 series BMW cars, three CAN networks are used. Among them, CAN power network and CAN car body network are connected to the central gateway module, which is then connected to the Byteflight star network. Byteflight star connectors are safety-critical control and information modules. The third CAN network connects CAS (Car Access System) to the door control unit and seat control unit (up to 11 units). CAS also provides an interface to the CAN car body network, which includes up to 20 nodes. Network software structure The software structure of TCU and remote diagnosis system is shown in Figure 2. The diagnostic system runs a general web browser to view the information provided by the web server on the TCU. By implementing a web server on the TCU, the car manufacturer can provide a diagnostic interface that can be accessed without knowing the implementation details in advance (it may change even within the same model year), The advanced drivers in each CAN node implement application-specific protocols in response to requests received from the network server. The driver is responsible for analyzing and decoding PDUs (protocol data units) and generating various local tasks that satisfy the required behavior of PDUs. Once the local tasks are completed, any results generated by these tasks will be formatted and returned to the network server via the CAN bus. The DNC (Dynamic Node Configuration) server maintains a list of active nodes. When a node is added (can be "hot add" or "cold add") to the CAN network, it immediately starts broadcasting configuration requests to the DNC server running on the TCU. Because the Dynamic Host Configuration Protocol (DHCP) used by many computers is used for modeling to automatically obtain the network configuration, a similar (simplified) protocol can be used to allow CAN nodes to obtain certain required network configuration data. Through this mechanism, nodes can be added or deleted in a similar way to plug and play in the computer. CAN nodes use DNC requests to publish their randomly generated node ID numbers, that is, they want to be used as an "alias" for their name or "address" on the CAN network (do not use it with message-based filtering or IDs used on CAN networks Number confused). When the DNC server of the TCU receives a DNC request, it first checks that the ID number requested by the node is valid and does not conflict with any other nodes on the current network. Then, the server checks that it has enough storage space to add the node's configuration table to its active node list. Finally, if the above check is passed, the DNC server will accept the request and assign a unique number to the node as the name during its activity. At the same time, the ID number of the node will also be added to the server's active node list. All future communications to this node will use this protocol ID. If the requested ID number is invalid, the TCU will reject the request, prompting the node to request another ID number until the ID number can be accepted. The TCU acts as the host of the CAN network because the CAN node itself does not run a protocol stack based on TCP / IP. When a web browser needs to access a CAN node, it communicates with a web server. The web server interprets the action requested by the browser and generates communication on the CAN network to perform the action. An example of a TCU processor is CP3BT26 of National Semiconductor, which belongs to the CP3000 series of connectivity processors. It has the following characteristics: * 24MHz 16-bit RISC CPU, including 32-bit expansion; * 256K bytes of on-chip flash memory; * 8K bytes data flash memory (writable when executed from 256K flash memory); * 32K bytes of static memory; * Bluetooth baseband controller; * Dual CAN 2.0B active controller with target storage (called fullCAN); * USB 1.1 full speed node; * ACCESS.bus, SPI, Microwire / Plus low overhead chip-chip bus; * Four UARTs; * AAI codec interface (compatible with SSI interface); * 8-channel 12-bit AD converter; * 54 general purpose I / O port pins; * General timer; * Watchdog timer; * Low voltage mode; The device has a complete Bluetooth and TCP / IP protocol stack, and its support includes a set of pre-tested software development tools, peripheral drivers and real-time operating system. SMD Electric Power tansformer ,POE transformer ,EP7 SMD tansformer ,EP13SMD tansformer，EPD SMD tansformer IHUA INDUSTRIES CO.,LTD. , https://www.ihua-coil.com
Figure 1: Network architecture and remote diagnostic interface. 
Figure 2: Software structure of TCU and diagnostic system